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© The invention relates to an unstaffed checkout 
system comprising a checkout counter (1) provided 
with appropriate actuators, a background system 
(17) containing at least the product data, and a cash 
terminal program (15) which transmits information 
from the checkout counter actuators to the back- 
ground system. The system comprises a functional 
block (13) with an interface (14) compatible with the 
data transmitted by the cash terminal program (15). 
Product data relating to product identification are 
collected and new data are automatically added to 
the data for each product until the system has 
learned the key characteristics of each product. 
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The present invention relates to an unstaffed 

T*" C ° mpriSin9 3 Check0 ^ « 
prided wrth appropriate actuators, a background 
system containing at least the product data and a 

from IT'"* ? r ° 9ram WhiCh tranSmits information 
from the checkout counter actuators to the back- 
ground system. Ck 

One of the previously known checkout systems 
s presented in patent application no. GB 2161631 

Innl r S °!u i0n ' ° ne sa,es P er son takes care of 
collecting the money from the customers, who 

S2r I Che ?° Ut C ° Unter e 9 ui Pment, feed the 
identification data for the products they have 
bou ghl , nt th casn systQm of ^ y have 

1JJ > b ° U9ht h3Ve been P^ted to the 
checkout counter in an acceptable manner, the 
customer may proceed further and receives a re- 
ceipt on the basis of which he/she is then charged 
by the salesperson. A problem in this prior-art 
solutKjn ,s that it still requires a salesperson to 
collect the money and a space for him/her to work 
•n. Th.s space naturally reduces the effective area 

SLTl t°K M ° re0Ver ' the product identification 
« te "P^ted separately every time new 
products are brought for sale or the data for old 
products are changed. The updating process in- 
volves a nsk of error because it may be neglected 
and because the data may be incorrectly put into 
r a nn SV t K m fl A fUrther drawbaCk is that this system 

terns e ( X ' b,y 8dded t0 eXiSt,n 9 Checkout sys- 

terns but replaces the whole existing system Con- 

Sann £ *" * ^^-and inTtexSe. 

Yet another serious drawback is that file updates 
are not effected via a background system, so each 
checkout counter must contain its own product data 
and product .dentification data until the data are 
ranste-red manually or otherwise separately into 
the other machines. As a result, the machines 
practical always have slightly different data and 
the system cannot be self-learning 

nat/^ 0 ^ ° f the PreSent invention is f° elimi- 
nate the drawbacks referred to above and to 

ach,eve a reliable, cheap and self-updating unstaf- 
fed checkout system. The invention is character- 
-zed by what is presented later on in the Cats 
The mvenhon has the advantage of reducing the 
need for sales personnel and providing easy con- 
nector, to existing checkout systems. Via an inter- 
In^? ? identification P ro 9ram constituting a 
separate functional unit is Hnked by software with 
an e XI st,ng cash terminal program. The interface 
«on nJ° Standardi2ed that the product identifica- 

-Zi tZ am , ^ be ,,eXib,y ' inked with dif f«rent 
.ash terminal programs as the interface data are 
always compatible and the cash terminal program 
mows what data is transmitted by the produS 
dentification program and vice versa. When the 
nterface ,s a variable, variable address or memory 



locat on mutually agreed on by the program suppli- 
ers the result is an extremely cheap and usable 
mterface. A further advantage is the self-learning 
capability of the system, which means that new 
IT f "tification data or changes in the old 

fSL T, I™* necessari, y be coated for the ma- 
chine but the system learns the new data itself 

th. V h ! f0 " 0win 9- t" e '""venti-on is described by 
the aid of an example by referring to the attached 
io drawings, in which 

Fig. 1 presents an overall view of the chec- 
kout counter of the invention in a per- 
spective drawing, 
Rg. 2 presents a block diagram of an em- 
bodiment of the system of the inven- 
tion, showing how the actuators are 
connected to the system, 
F'9- 3 presents a functional block diagram of 
„ representing the recognition of a bank 

or other card and the input of the 
starting data. 
Fig- 4 presents a functional block diagram of 
the functions of the scanning block of 
the checkout counter, 
25 Fig. 5 presents a functional block diagram of 
the functions of the learning block of 
the checkout counter. 
Fig. 6 presents a functional' block diagram of 
the functions of the EAN-code block 
of the checkout counter, 
Fig. 7 presents a functional block diagram 

representing the handling of errors 
Fig. 1 illustrates the checkout counter 1 of' the 
invention. Depending on the need, the shop is 
35 provided with one or more checkout counters 
which are p.aced e.g. side by side with a passage 
between them leading out of the shop space The 
passage is blocked by a gate, which is opened 
after an accepted transaction. Each checkout coun- 
ter ,s connected to the electric network and, by 
means of a connecting cable, to the shop's central 
computer, which runs the background system The 
connections to the electric network and the central 
45 £hn ^ imp,ernen ted using conventional 
JST?" 50 th6y ^ n0t Presented in *e draw 

icanni T T* ° f "™ CheCk ° Ut COUnte r is a 
d^t, ; Wh ° Se fUnCti ° n iS t0 rec °9"ize all pro- 
duc s marked with a bar code. The customer 

so ovT^ PaSS8S the products ne/sh e has bought 

P7ace the C nT ^ thS SCannin9 ' the custo ™ 
d ovWph r UCt ° n 3 be,t conve y° r - w hich is 
provided with a weighing device for determining 
the weight of the products. The weigher iTS 
under the belt conveyor and is not visibte in the 
d r m9 M Sim,lar,y ' the b6,t COnve Vor actuator is 
inlr S : b h ' e "l the drawin 9 s teca ^ « is placed 
•ns.de the checkout counter. In the direction of 
motion of the belt conveyor, at the midd.e par, of K 
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there is a light screen 4 for the recognition of the 
shape of the products. The light screen extends 
from the level of the conveyor belt to a height 
sufficient to allow the recognition of all everyday 
products regardless of their height. At the entry 
end of the checkout counter there is also a monitor 
5 through which the customer is given the neces- 
sary instructions, and also a bank card reader and 
a PIN keypad 6, by means of which the customer 
can pay for the goods purchased. The belt con- 
veyor 3 delivers the products onto a trough belt 
conveyor 7 placed directly after it on the checkout 
counter. The trough belt conveyor moves the ac- 
cepted products into one of the troughs 11 pro- 
vided at the exit end of the checkout counter as 
guided by the distributor 8. The actuator of the 
trough belt conveyor 7 and the turning mechanism 
of the distributor 8 are placed inside the checkout 
counter and are not visible in the drawings. Both 
side edges of the checkout counter are provided 
with protective walls 9 placed alongside the trough 
belt conveyor 7 to prevent the products from falling 
off the counter. The protective walls 9 also prevent 
the customer from throwing any products past the 
light screen into the troughs 11. At the extremity of 
the exit end of the checkout counter there is a 
packing board 10 for ease of packing the products 
into a shopping bag. Moreover, inside the checkout 
counter there is a computer which is provided with 
all the necessary interface cards and which is used 
to run the product identification program 13, allow- 
ing unstaffed operation of the checkout counter. 
The actuators and the computer 16 inside the 
checkout counter are protected by the counter 
body, which is covered with side walls 12. 

Fig. 2 is a simplified presentation of an em- 
bodiment of the system of the invention, showing 
the main blocks of the product identification pro- 
gram 13 as well as the connections between the 
various actuators used in the checkout system on 
the one hand and the product identification pro- 
gram and the computer on the other hand. The 
broken line marked with reference number 1 in Fig. 
2 represents the checkout counter and the broken 
line marked with reference number 16 represents 
the microcomputer physically present in the chec- 
kout counter and used to run a program consisting 
of the product identification program 13 and the 
cash terminal program 15. The product identifica- 
tion program 13 and the cash terminal program 15 
are linked together via an interface 14 so as to 
allow interactive operation. The interface 14 is like 
a mailbox in which either program block may store 
data to be read by the other block. For each data 
type there is a separate interface agreed on by the 
program suppliers, so the program which writes or 
reads data in an interface knows automatically the 
type of data to be written or read in each interface. 
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The data types referred to include scanning start 
permission, credit card code inquiry, EAN data, 
acceptance data, keyboard input data and file up- 
dates. In practice, the interface 14 is a series of 
5 variables, variable addresses or memory locations 
in the computer memory. 

The card reader and PIN keypad 6 is plugged 
into the computer's keyboard connector. This ac- 
tuator is only used to supply input data to the cash 
10 terminal program, this being indicated in Fig. 2 by 
an arrow pointing from the actuator block towards 
the cash terminal program block 1 5. The bar code 
reader or scanner 2 is connected to the COM2 port 
of the computer, the weigher to the COM3 port and 
75 the background system 17 run in the central com- 
puter of the shop is connected to the COM1 port of 
the checkout counter computer. The modem, which 
is used for the transmission of advertisements and 
maintenance data, is connected to the COM4 port 
20 of the checkout counter computer. The bar code 
reader and the weigher supply only input data to 
the product identification program 13, whereas the 
background system and the cash terminal program 
15 may communicate in both directions. Similarly, 
25 a two-way data transmission link is provided be- 
tween the modem and the product identification 
program. All the above-mentioned COM ports are 
standardized serial ports connected to the serial 
communication bus of the computer. 
30 The receipt printer is connected to a parallel 

port, e.g. a Centronics interface, and the monitor 5 
is connected to a VGA port. The rest of the ac- 
tuators are connected to the checkout counter 
computer via a separate I/O card provided with 
35 input pins for the data supplied by the light screen 
4 for shape recognition, by the PIN-keypad and for 
various sensor data. These sensor data include 
trough-empty data for the right-hand and left-hand 
troughs, data indicating the final limit of the belt 
40 conveyor 3 and data indicating the right-hand and 
left-hand limits of the distributor 8. Moreover, the 
same I/O card is provided with pins for the output 
data needed by the control electronics for the 
control of the belt conveyor 3, the trough belt 
45 conveyor 7, the turning device of the distributor 8 
and the lock of the customer gate. The customer 
gate, the function of which is to open the passage 
for the customer to exit from behind the checkout 
counter after the products have been accepted and 
so paid for, is not shown in the drawings. The commu- 
nication 18 between different checkout counters, 
mainly consisting of the transmission of updated 
product and product identification data, takes place 
via the background system 17. In the mass storage 
55 of the background system there is a file containing 
the product data, of which certain items, such as 
the EAN code, the price and the product name, are 
transmitted via the cash terminal program 15 into a 
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product file in the mass storage of the product 
identification program 13. In this same file the 
product identification program collects product 
identification data, such as product weight, height 
etc., to be used in the learning process and trans- 
mitted via the background system to the other 
checkout counters. This provides the advantage 
that the learning routine need not be repeated 
separately in each checkout counter. 

Fig. 3 shows a functional block diagram repre- 
senting the reading of the bank card. For the sake 
of clarity, the text appearing on the monitor screen 
is presented in separate blocks and enclosed in 
quotes. When a customer comes to the checkout 
counter, he/she starts the product identification and 
payment procedure by first communicating with the 
customer terminal. First, the customer terminal 
wants to read the bank card or equivalent and asks 
the customer to insert his/her card into the card 
reader Depending on the actual equipment used 
the card .s either inserted into the machine or just 
slid past its read head. The monitor displays the 
appropriate text in each case. Next, the program 
prompts the customer for a personal code number 
and performs a comparison to check whether the 
number given is correct. If the number was not 
right, the program outputs a corresponding mes- 
sage via the monitor and asks the customer to 
input his/her personal code number again. After the 
correct number has been input, the program can 
proceed further and asks the customer to select 
the manner of payment. In practice, there are three 
alternative ways: bank card, credit card or a com- 
bination of these. After the customer has typed in 
his selection for the manner of payment, the pro- 
gram contacts the background system and com- 
pares the customer data against a checklist in the 
background system to see if the customer's card 
and payment mode selection are acceptable. If the 
card or the payment mode was uncacceptable a 
corresponding message is output via the monitor 
and the customer is prompted to remove the card 
if it is still in the reader. At the same time, the 
program flow returns to the beginning and the 
customer is asked to insert another card If the 
payment mode selected was acceptable, the moni- 
tor displays a message asking the customer to 
remove the card if it is still in the reader and the 
program gives a permission to start the transaction 
Next, the program checks whether one of the 
troughs 11 at the exit end of the checkout counter 
is empty. When either one of the troughs is empty 
the checkout counter can be started, the distributor 
8 is turned to the appropriate position and a suit- 
able instruction, e.g. "START SCANNING", is dis- 
played by the monitor. After this, program control 
is handed over to the functional block shown in Fig 



Fig. 4 presents the scanning block, i.e. the bar 
code reading block. The basic function in this block 
consists in the program waiting until scanning has 
taken place. At this stage, it is important for the 
s system to be able to ensure that no products are 
moved directly past the scanner, the weigher or the 
light screen. Also, the program checks that there 
are not too many products at the same time on the 
belt conveyor and that a new product can only be 
10 scanned after the previous one has been weighed 
First, the program checks whether a product has 
been scanned. If no scanning has taken place the 
program reads the weight from the weigher 'and 
then checks whether a change has occurred in the 
rs light screen. If no change has taken place the 
program checks whether the weight indicated by 
the weigher has changed. If there is no change in 
the weight, either, the program checks whether a 
wait flag has been set. A wait flag must be set for 
20 the shape recognition at the light screen because 
the scanning and weighing are very fast operations 
whereas moving the product through the light 
screen takes a much longer time. Setting the wait 
flag enables the system to know that measurement 
25 .s still going on at the light screen, so the system 
will avoid producing incorrect data or error states 
While measurement is going on at the light screen' 
one of the photocell connections is still blocked If 
the wait flag was not set. the action returns to the 
30 beginning, i.e. the program continues waitinq for 
scanning. a 

On the other hand, if the customer has 
scanned a product, a corresponding scanning mes- 
sage is transmitted via a serial port to the product 
35 identification program. The EAN code of the prod- 
uct is now read into register E, which contains the 
running number of the product scanned. Moreover 
the value of register E is increased by one to 
enable the system to know how many products 
40 have been scanned and how many products are to 
be expected to arrive to the weigher. The first 
product that was brought onto the weigher must 
also be the first to be removed from it. otherwise 
an error has occurred. Next, the program checks 
« the product file to see if it contains the EAN code 
of the product. This function corresponds to the 
code inquiry function shown in Fig. 2. If the' EAN 
code is not found in the background system of the 
shop, the cash terminal program in the checkout 
so counter cannot use the EAN code in question and 
m this case the checking operation results in an 
ERROR function, which is presented as a block 
diagram in Fig. 7. When the ERROR function is 
activated, a corresponding error message is output 
55 via the monitor 5 and the belt conveyor 3 is re- 
turned to the starting position. Next, a message or 
alarm signal is sent to the background room of the 
shop to allow the error to be acknowledged, i.e the 
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missing EAN code to be added to the background 
system. For each product, the following data items 
are written into the product file: EAN code, product 
name and price. Moreover, via the learning file, the 
system adds automatically certain product iden- 
tification data, such as weight, height, etc., to the 
product file. The computer in each checkout coun- 
ter has a product file in its mass storage, i.e. on its 
hard disk. Upon an alarm, the new product may be 
added via a touch-screen e.g. by the shop supervi- 
sor. After the addition, the program returns back to 
the scanning block, to the function from which the 
ERROR function was started. If and when the EAN 
code is found in the product file, the program again 
continues monitoring the weigher and the light 
screen. For example, the customer may attempt to 
throw the product through the light screen so that it 
will not land on the weigher. Suppose the product 
has been placed in the normal manner on the belt 
conveyor 3, where it is weighed immediately. As 
yet, no change has taken place in the light screen, 
so the next check is whether a change has oc- 
curred in the weight indicated by the weigher. 
Since the product is on the belt conveyor 3, a 
change in the weight has occurred, and in this case 
a new check is performed to ascertain whether the 
product has been removed from the weigher. If the 
equation weight(meas) = weight(prev) - weight(1) 
becomes true, this means that product(1) has been 
removed from the weigher. In this equation, weight- 
(meas) is the value indicated by the weigher at the 
time of measurement, weight(prev) is the previous 
value measured by the weigher and weight(1) is 
the weight of the first product in the queue, i.e. of 
the product which is to he the first to be removed 
from the weigher. After this, the weigher register is 
decreased by one, weight(prev) is set to the value 
of weight(meas), i.e. the weigher is set for the 
product in question. Next, a check for the light 
screen is performed to establish whether the wait 
flag has been set, i.e. whether a photocell has been 
lit. In a normal situation, product(1) has not yet 
passed through the light screen at this stage, so 
the correct result of the checking operation must 
be "no", otherwise an error has occurred. If the 
equation weight(meas) = weight(prev) - weight(1) 
does not become true during the above-mentioned 
check, the program must check whether the EAN 
code has been read into register E. If in this 
situation the EAN code has not been read into 
register E, this means that no scanning has yet . 
been performed but a change has nevertheless 
occurred in the weight indication. This produces an 
error situation and activates the ERROR fucntion. 
Similarly, if the equation weight(meas) = weight- 
(prev) - weight(1) does not become true in the 
above-mentioned checking situation but the latter 
check indicates that the EAN code has been read 



into register E, the program proceeds to block A in 
the teaching procedure presented in Fig. 5. In this 
procedure, error recognition takes place, which is 
required to ensure that the data learned are cor- 
5 rect. 

First, the system checks whether the weight of 
the product scanned is correct. If it is, program 
execution continues from the light screen block 
(LSBLK), which is presented in Fig. 4. In this block, 
io the system first sets wieght{n)= weight(meas)- 
weight(prev), where n is the running number of the 
product being weighed. By means of this number it 
is possible during continuous weighing to detect 
the weight of each separate product brought onto 
75 the weigher even though there is a continuous flow 
of products arriving to, staying on and being re- 
moved from the weigher. Next, the value of the 
weigher register is increased by one and the 
weigher is reset, weight(prev) is set to the value of 
20 weight(meas), whereupon the program returns to 
the scanning block to check whether a change has 
taken place in the light screen. 

If in the learning block presented in Fig. 5 the 
weight of the product scanned was not correct, 
25 then it is necessary to check whether the number 
of samples is full. The number of samples is a 
certain preselected number which ensures a good 
learning result with the required probability. The 
number of samples may have values e.g. between 
30 0-9. If the number of samples was not full, the 
weight is accepted, the product identification data 
is stored in the learning data file and program 
execution continues again from the light screen 
block (LSBLK), whereafter execution is back in the 
35 normal scanning block. Similarly, if the same kind 
of product has been passed through the weigher so 
many times that the number of samples becomes 
full at this stage of the learning block, the result is 
an error situation because there is now something 
40 wrong with the weight. In a normal situation this 
learning phase would not have been needed. A 
typical fault leading to this situation could be e.g. 
that a one-litre milk carton has lost so much milk 
through leakage that its weight is no longer within 
45 the tolerance range. In this situation the system 
helps the customer get a good product of the 
proper weight. 

Now, let us consider the learning block and the 
passage of the product through the light screen. In 
so Fig. 5, the relevant block is SCBLK-B, to which the 
program jumps from the scanning block when a 
change has occurred in the light screen and the 
lowest light cell is off. In this case, the program first 
resets the wait flag, then reads the light screen into 
55 register m, where m is the running number of the 
product under measurement, and increases the 
height register value by one. Next, it checks wheth- 
er height x, y or z is equal to the height of product- 
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(1). Product(1) again stands for the first product in 
the queue. If this check yields a positive result, the 
program then checks whether the number of sam- 
ples is full. If it is, the height register value is 
decreased by one and execution is continued from 6 
the EAN block, which is presented in Fig. 6. If the 
he.ght check gives a negative result, the program 
again checks whether the number of samples is 
full. In a normal situation, this check gives a nega- 
tive result, whereupon the sample counter of the 10 
product file is increased by one and the process 
continues by checking the number of samples 
aga.n. The sample counter value is only increased 
after the product has passed through the weigher 
and the light screen. If the number of samples is , s 
st.ll not full, the product identification data are 
stored in the learning file and the height register 
value is decreased by one, whereupon execution is 
transferred to the EAN block. On the other hand if 
this check yields a full number of samples, the 20 
program calculates the average values in the learn- 
ing file for the item in question, writes the product 
identification data into the product file, deletes the 
learning files, transmits the product identification 
data to the other checkout counters, decreases the 25 

I' 69 ' 816 ' Va ' Ue by one and P^eeds to the 
tAN block. The transmission of the product iden- 
tification data to the other checkout counters is 
shown in Fig. 2 as a "file updates" function, which 
transfers update data between the cash terminal 30 
program 15 and the product identification program 
13. The data to be sent to the other checkout 
counters are transmitted via the cash terminal pro- 
gram 15 first to the background system 17 and via 
the background system's data transmission link 18 3S 
further to the other self-service checkout counters 
In the event that the above-mentioned height check 
yields a negative result but the number of samples 
is full, an error situation is present because the 
system should already know all the correct height « 
values. In this case, a possible cause of error is 
that the customer has not scanned the product but 
slid it along the conveyor belt 3 through the light 
screen, As a result, the system has not been able 
to read the EAN code of the product and the <s 
product identification program 13 reacts to this as if 
the number of samples were full. Also, there may 
be something wrong with the product height data If 
this condition is true, the program jumps to the 
error block presented in Fig. 7. from where it 50 
returns to the scanning block as described before 
While the system is learning the weight and shape 
lata, the relevant data are stored in an auxiliary 
nemory until the preset number of samples is 
eached. After that, the average values of the data 55 
n question are saved in a product file in a perma- 
lent storage as described above. 

After the product has passed through the light 



screen, it is considered as being accepted and 
execution is normally transferred from the learnina 
block to the EAN block, presented in Fig. 6 . First 
the accepted EAN code is transmitted to the cash 
terminal program. The corresponding function is 
shown in Fig. 2 as "accepted code". Next, the 
trough belt conveyor 7 is kept running for a certain 
length of time to ensure that the products are 
brought into the correct trough, the EAN register is 
decreased by one and a check is performed to 
ascertain whether the product arriving from the 
light screen was the last one. If it was not the last 
product, execution returns to the scanning block 
whereas if it was the last product, the exit gate is 
opened for the customer, the belt conveyors are 
stopped after a suitable delay and the transaction 
is terminated. In addition, the receipt printer is 
given instructions to print out the receipt for the 
customer. This function is performed in Fig 2 
under "keyboard data", which is also the route 
used to transmit the termination signal to the cash 
terminal program. In addition to the manual ter- 
mination signal, other information and messages 
may be typed in through a touch-screen, for exam- 
ple a request for help if the system does not 
function properly. In this case, the supervision per- 
sonnel of the shop will assist the customer. 

It is obvious to a person skilled in the art that 
the invention is not restricted to the examples 
described above, but that it may instead be varied 
within the scope of the following claims. Thus far 
example the interface (14) agreed on by the suppli- 
ers of the product identification program (13) and 
the cash terminal program (15) may be a normal 
mechanical connection with pins or connector sur- 
faces provided separately for each data type. In 
this case each program (13, 14) works separately 
possibly even in different computers or processors 

Claims 

1. Unstaffed checkout system, comprising a 
checkout counter (1) provided with actuators a 
background system (17) containing at least the 
product data, and a cash terminal program (15) 
which transmits information from the checkout 
counter actuators to the background system 
characterized in that 

- the system comprises a functional block 
(13) with an interface (14) compatible 
with the data transmitted by the cash 
terminal program (15), 

- data transmission between the functional 
block and the cash terminal program 
takes place via the interface (14) in the 
functional block, 

- product data relating to product iden- 
tification are collected in the functional 
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block and new data are automatically ad- 
ded to the data for each product until the 
system has learned the product iden- 
tification data typical of each product. 

2. Checkout system according to claim 1, char- 
acterized in that the functional block (13) in- 
stalled in each checkout counter (1) is placed 
in a microcomputer (16) provided in each 
checkout counter so that the functional block 
(13) is linked as an extension to the existing 
cash system. 

3. Checkout system according to claim 1 or 2, 
characterized in that the interface (14) be- 
tween the functional block (13) installed in 
each checkout counter (1) and the cash termi- 
nal program (15) is an agreed variable, variable 
address or memory location in which the data 
collected and transmitted by the functional 
block is stored and from which the cash termi- 
nal program reads the data for subsequent 
further processing. 



4. Procedure for accomplishing a transaction in 25 
an unstaffed checkout system as defined in 
claim 1, characterized in that the procedure 
comprises at least the following stages: 

- reading the credit card, 
accepting/rejecting the credit card and 30 
mode of payment for the checkout sys- 
tem 

- upon acceptance, starting the checkout 
counter, turning the distributor (8) and 
starting the scanning 35 

- checking the scanning result, weighing 
the products and recognition of product 
shape 

- after the weighing and shape recognition, 
comparing to the data obtained by scan- aq 
ning and to the data in the product file 

- as a result of the comparison, learning 
the product identification data and saving 
them in a storage if the system does not 
already have sufficient information about 45 
the product 

- accepting the sale of the product 

- conveying the product into a trough (11) 
for the customer to take away, opening 

the exit gate for the customer and stop- 50 
ping the operation of the checkout coun- 
ter. 
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